Sams Teach Yourself MCSE Windows NT Server 4 in 14 Days
(Publisher: Macmillan Computer Publishing)
Author(s): David Schaer, et al
ISBN: 0672311283
Publication Date: 12/15/97

As your organization grows, however, moving to a multiple domain model might become necessary. For example, Microsoft indicates that the maximum size for an NT Directory Services database not exceed 40MB, approximately 20,000 users along with groups and computer accounts. If your database grows larger than this, splitting your network into two or more domains will become necessary.

There are several good things about the single domain model:

•  Managing user and group accounts is easier because they are all in one place.

•  Administering resources is easier because they are centrally located.

•  Security is centralized.

It might be time to consider another model in the following circumstances:

•  The size of your NT Directory Services database grows to more than 40MB or you have more than 20,000 users.

•  You must divide the management of resources by department or geographical location for administrative purposes.

2.8.2. Master Domain

In the master domain model, multiple domains are defined and linked by trust relationships. One domain, the master domain, contains all the user accounts. Other domains are configured as resource domains and contain the various resources used on the network. This model is represented in Figure 2.20.

Figure 2.20.  The master domain model.

In this example, all network users log on to the Chicago master domain because all user accounts reside there. When a user is logged on to the Chicago master domain, she can access any resources located in any domain that trusts the Chicago master domain. For example, a user in Fargo can log on to the Chicago master domain and access the color plotter in the Sales domain.

Remember that a user’s physical location is unimportant in this process. A user always logs on at a computer in a domain that trusts the Chicago master domain to log on to the Chicago master domain via pass-through authentication.

In this model, the resource domains are divided by department, each of which trusts the Chicago domain. This model assumes that the Chicago domain is sufficiently secure that the resource domains can entrust their resources to it. This model gives the advantage of having the user accounts administered centrally, while each department manages its own resources.

Managing groups becomes a little more complex in this model because of the way in which trust relationships work. Remember that user accounts in the trusted domain must be put into global groups. The global groups must then be put into local groups in the trusting domains. These local groups are then assigned permissions to use resources, as shown in Figure 2.21.

Figure 2.21.  Managing groups in a master domain model.

In this figure, user accounts in the Chicago domain must be put into a global group in the Chicago domain. That global group can then be placed into a local group in the Sales (or Finance) domain. That local group can then be assigned permissions to access resources.

The master domain model is good because

•  Security management is centralized. Only one user account database exists.

•  Resource domains can be used to organize resources by department or by geographical location.

You might have to consider another model when the size of your NT Directory Services database grows to more than 40MB or you have more than 40,000 users.

2.8.3. Multiple Master Domain

The multiple master domain model takes the concept of the master domain model one step further. In this model, multiple domains contain the user accounts for the net-work. These are the master domains. There are also multiple resource domains, each of which trust every master domain. Consider the example in Figure 2.22.

Figure 2.22.  The multiple master domain model.

In this example, all users log on to either the Chicago domain or the Fargo domain, depending on where their user account is located. When they are logged on, these users can access the resources on any domain that trusts the domain on which they are logged.

This model makes managing groups even more complex. Now, in order for any user to be able to access resources, the same global groups must be created in each master domain, and each of these global groups must be placed into local groups in the resource domains. Consider the example in Figure 2.23.

Figure 2.23.  Managing groups in the multiple master domain model.

In this example, things are a little more complex than in the master domain model. Users in both the Chicago and Fargo master domains must access a resource in the Finance resource domain in Chicago. The first step is to create appropriate global groups in both the Chicago and Fargo master domains. Each of these global groups must then be placed into the local group in the Finance domain. Permissions are then assigned to that local group. You can see that group management in the multiple master domain model can quickly grow quite time-consuming as more master domains are introduced.

The multiple master domain model is good because

•  Security management is centralized.

•  Resource domains can be used to organize resources by department or by geographic location.

The following are the disadvantages of the multiple master domain:

•  The number of groups and trust relationships rises dramatically with each new master domain that is added.

•  User accounts are not centrally located, forcing many groups to be duplicated among master domains and increasing the complexity of user account management.

The formula for calculating the number of trusts in a relationship is M(M–1) + (RM). In this formula, M is the number of master domains and R is the number of resource domains.